home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-manning-dns-nsap-01.txt
< prev
next >
Wrap
Text File
|
1993-04-05
|
19KB
|
621 lines
Network Working Group B. Manning (Rice University)
INTERNET DRAFT R. Colella (NIST)
05 Apr, 1993
DNS NSAP RRs
Status of This Memo
This memo refines the approch taken in RFC 1348, updating the processing
methods for encoding of NSAP addresses for the Internet community. Discussion
and suggestions for improvement are requested.
This document is an Internet Draft. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working documents as
Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other documents at
any time. It is not appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet Draft.
It is intended that this document will be submitted to the IESG for
consideration as a standards document. Distribution of this document is
unlimited.
Abstract
The Internet is moving towards the deployment of an OSI lower layers
infrastructure. This infrastructure comprises the connectionless network
protocol (CLNP) and supporting routing protocols. Also required as part of
this infrastructure is support in the DNS for mapping between names and NSAP
addresses.
This document redefines the format of two new Resource Records for the Domain
Name System, as defined in RFC 1348. This format may be used with any OSI NSAP
address format.
Expiration: 05 Oct, 1993 [Page 1]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Structure of NSAPs . . . . . . . . . . . . . . . . . . . . 6
5 NSAP RR specification . . . . . . . . . . . . . . . . . . . 6
5.1 The NSAP RR . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 The NSAP-PTR RR . . . . . . . . . . . . . . . . . . . . . . 6
6 DNS Operation for NSAPs . . . . . . . . . . . . . . . . . . 6
7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
8 Security Considerations . . . . . . . . . . . . . . . . . 6
9 References . . . . . . . . . . . . . . . . . . . . . . . . 6
10 Author's Address . . . . . . . . . . . . . . . . . . . . . 6
A Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6
B. Manning (Rice University) [Page 2]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
1 Introduction
The Internet is moving towards the deployment of an OSI lower layers
infrastructure. This infrastructure comprises the connectionless network
protocol (CLNP) [ISO8473] and supporting routing protocols. Also required as
part of this infrastructure is support in the Domain Name System (DNS)
[RFC1034, RFC1035] for mapping between DNS names and OSI Network Service
Access Point (NSAP) addresses [ISO8348Ad2] [Note: NSAP and NSAP address are
used interchangeably throughout this memo].
This memo redefines the format of two new Resource Records (RRs) for the DNS,
as defined in RFC 1348. This format may be used with any OSI NSAP format.
This memo assumes that the reader is familiar with the DNS. Some familiarity
with NSAPs is useful; see [RFC1237] or [ISO8348Ad2] for additional
information.
2 Background
The reason for defining DNS mappings for NSAPs is to support CLNP in the
Internet. Debugging with CLNP ping and traceroute is becoming more difficult
with only numeric NSAPs as the scale of deployment increases. Current debugging
is supported by maintaining and exchanging a configuration file with name/NSAP
mappings similar in function to hosts.txt. This suffers from the lack of a
central coordinator for this file and also from the perspective of scaling.
The former is the most serious short-term problem. Scaling of a hosts.txt-like
solution has well-known long-term scaling difficiencies.
A second reason for this work is the proposal to use CLNP as a replacement
for IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for
Internet Addressing and Routing" [RFC1347]. Should this proposal be selected,
the DNS must be capable of supporting CLNP addresses.
3 Scope
The RRs defined in this paper support all known NSAP formats. In addition,
the RRs support the notion of a custom-defined NSAP format. There are several
ways in which an NSAP can be defined. To illustrate this feature, examples in
this memo will assume that the Internet obtained an AFI from ISO and defined
a fixed-field NSAP format.
As a point of reference, there is a distinction between registration and
publication of addresses. For IP addresses, the IANA is the root registration
authority and the DNS a publication method. For NSAPs, ISO8348/Ad2 is the
root registration authority and the DNS is being proposed as a publication
method.
B. Manning (Rice University) [Page 3]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
4 Structure of NSAPs
NSAPs are hierarchically structured to allow distributed administration and
efficient routing. Distributed administration permits subdelegated addressing
authorities to, as allowed by the delegator, further structure the portion of
the NSAP space under their delegated control. Accomodation of this
distributed authority requires flexibility in the DNS representation of
NSAPs, allowing sub- authorities to represent the substructure they define, if
any, in the DNS as well as the NSAP values themselves.
While all NSAP structures currently known to be in use in the Internet have
fixed field sizes (e.g., [RFC1237, IPTAG-92-23-PB660], some NSAP formats
defined in ISO 8348Ad2 define one of the fields as variable-sized. These
formats are still parsable, since the total NSAP length is known and there
is, at most, one variable-sized field. These formats are accomodated in this
document, even though there is no current requirement. The notation is fully
described in Section 5.2, "The NSAP_PTR RR" and the processing in Section 6,
"DNS Operation for NSAPs."
For the purposes of this memo, NSAPs can be thought of as a tree of
identifiers. The root of the tree is defined in Addendum 2 to ISO8348
[ISO8348Ad2], and has as its immediately registered subordinates the
one-octet Authority and Format Identifiers (AFIs) defined there. The size of
subsequently-defined fields depends on which branch of the tree is taken. The
depth of the tree varies according to the authority responsible for defining
subsequent fields.
An example is the authority under which US GOSIP defines NSAPs [GOSIPv2FT].
Under the AFI of 47, NIST (National Institute of Standards and Technology)
obtained a value of 0005 (the AFI of 47 defines the next field as being two
octets consisting of four BCD digits from the International Code Designator
space [ISO6523]). NIST defined the subsequent fields in [GOSIPv2FT].The field
immediately following 0005 is a format identifier for the rest of the US
GOSIP NSAP structure, with a hex value of 80. Following this is the
three-octet field, values for which are allocated to network operators; the
registration authority for this field is delegated to GSA (General Services
Administration).
The last octet of the NSAP is the NSelector (NSel). In practice, the NSAP
minus the NSel identifies the CLNP protocol machine on a given system, and
the NSel identifies the CLNP user. Since there can be more than on CLNP user
(meaning multiple NSel values for a given "base" NSAP), the representation of
the NSAP should be CLNP-user independent. TO achive this, an NSel value of
zero will be used with all NSAP values stored in the DNS. An NSAP with NSel=0
identifies the network layer itself. It is left to the application retrieving
the NSAP to determine the appropriate value to use in that instance of
communication.
In the event that CLNP is used to support TCP and UDP services, the NSel
value used will be the appropriate IP PROTO value as registered with IANA.
For "standard" OSI, the selection of NSel values is left as a matter of local
administration. Administrators of systems that support support TP0-4 in
addition to TCP/UDP will select NSels for use by TP0-4 that do NOT conflict
with the IP PROTO vlaues.
For the purposes of this memo, we will present NSAPs as a string of
"."-separated hex values. This is common usage, not the "+" operator
specified in RFC1278. The values correspond to the fields in the NSAP, as
defined by the appropriate authority. For example, a printable representation
of the first four fields of a US GOSIP NSAP might look like
47.0005.80.005a00
and a full US GOSIP NSAP is
47.0005.80.005a00.0000.1000.0020.00800a123456.01.
For more information on US GOSIP NSAPs, see RFC1237 [RFC1237]. Other NSAP
formats have different fields and field widths; see the examples in Section 7
and also [IPTAG-92-23-PB660].
B. Manning (Rice University) [Page 4]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
5 NSAP RRs Specification
5.1 The NSAP RR
The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). The
NSAP RR has the following format:
< owner> < ttl> < class> NSAP < rdata>
All fields are required.
The < owner> is the DNS name for the system that is addressed by the NSAP in
the < rdata> field (see below).
The meaning of the < ttl> field is as specified in RFC1034.
The format of the NSAP RR is class insensitive.
The < rdata> is a complete NSAP address expressed in the dotted hexidecimal
notation as described in Section 7.
NSAP RR causes no additional section processing.
5.2 the NSAP-PTR RR
The NSAP-PTR RR is defined with mnemonic NSAP-PTR and type code 23 (decimal).
It's function is analogous to the PTR record used for IP addresses [RFC1035,
RFC1103], although the details of how it operates are different. The NSAP-PTR
RR has the following format:
< owner> < ttl> < class> NSAP-PTR < rdata>
All fields are required.
The < owner> is a complete NSAP or an NSAP prefix. The octets of the NSAP are
in reverse order, with the least significant octet on the left and the AFI octet
on the right. The reversal is on an octet boundary. The dotted hexidecimal
notation described in Section 7 is used to separate the NSAP fields.
The meaning of the < ttl> field is as specified in RFC1034.
B. Manning (Rice University) [Page 5]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
The format of the NSAP-PTR RR is class insensitive.
The < rdata> field consists of two subfields separated by one or more spaces
or tabs. The first subfield is a DNS name that corresponds to the owner of this
NSAP prefix. In the case of an incomplete NSAP (i.e., an NSAP prefix), this
subfield must name the root with a single ".".
The second subfield of < rdata> contains structure information for subsequent
fields of the NSAP, to the extent that they are known at this level of the NSAP
tree. Strictly speaking, only the size of the next field is required to
navigate the DNS NSAP tree. However, for efficiency the NSAP structure
information should be included as far up towards the root as possible.
The format of this subfield is a set of "."-separated decimal digits
representing the sizes of fields subsequent to the NSAP prefix given in the
< owner> field. [Should we have a BNF for this?] A trailing "." indicates
that the structure information is complete. For leaf entries (i.e., when the
< owner> contains a complete NSAP), this subfield must contain a single ".".
The NSAP-PTR RR causes no additional section processing.
6 DNS Operation for NSAPs
Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP
address lookup. A query
is generated by the resolver requesting an NSAP RR for a provided DNS name.
NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse lookup
for IP addresses due to the structure of NSAPs and the requirements this places
on the lookup process.
The NSAP-to-name scheme operates with minimal a priori knowledge of how NSAPs
are structured and operates according to a simple algorithm. Given an NSAP to
be resolved, the only a priori information needed is that the first field of
all NSAPs is one octet. The basic algorithm operates as follows:
1.build an initial query to read the record associated with the first octet.
2.knowledge of the NSAP structure is not complete, so set (COMPL-KNOW = FALSE).
3.send the query.
4.when the response is returned, if (COMPL-KNOW == TRUE), done.
5.construct a more detailed query with the additional structure information from
the response.
6.if the structure information returned in step 4 ends with a ".", then set
(COMPL-KNOW = TRUE).
B. Manning (Rice University) [Page 6]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
7.go to step 3.
The a priori knowledge required is that all NSAPs begin with an initial
one-octet field, the AFI (Authority and Format Identifier, see [ISO8348Ad2]);
this is captured in step 1.
Steps 3 through 7 represent a simple learning algorithm in which the resolver
issues queries that are increasingly detailed until the result is obtained.
Successful termination, step 4, occures if the last query sent was based on
complete NSAP structure information, as determined by the trailing ".".
7 Examples
Three examples are presented. The first uses US GOSIP NSAPs, the second a
fictitious NSAP structure based on the idea of an Internet-assigned AFI, and the
third demonstrates the scheme in the presence of a variable-length NSAP
field.
;;;;;;
;;;;;; GOSIP-style NSAP.
;;;;;;
<owner> <class> <type> <rdata>
. IN NSAP 47
. IN NSAP 47.0005
. IN NSAP 47.0005.80
nist.gov IN NSAP 47.0005.80.005a00
emu.ncsl.nist.gov IN NSAP (
47.0005.80.005a00.0000.1000.0020.00800a123456.01)
47 IN NSAP-PTR . 2
0500.47 IN NSAP-PTR . 1
80.0500.47 IN NSAP-PTR . 3.2.2.2.6.1.
005a00.80.0500.47 IN NSAP-PTR nist.gov 2.2.2.6.1.
01.5634120a8000.2000.0010.0000.005a00.80.0500.47
IN NSAP-PTR emu.ncsl.nist.gov .)
;;;;;;
;;;;;; Internet AFI-based NSAP.
;;;;;;
;
B. Manning (Rice University) [Page 7]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
; Assume XX is the Internet AFI, and XX-based NSAPs have
; a fixed 19-byte format:
; 1.1.3.3.4.6.1.
; where the numbers indicate field sizes in octets.
;
<owner> <class> <type> <rdata>
. IN NSAP XX
. IN NSAP XX.12
bb IN NSAP XX.12.123456
reg.bb IN NSAP XX.12.123456.151617
host.reg.bb IN NSAP (
XX.12.123456.151617.37383930.414243454647.89)
XX IN NSAP-PTR . 1.3.3.4.6.1.
12.XX IN NSAP-PTR . 3.3.4.6.1.
563412.12.XX IN NSAP-PTR bb 3.4.6.1.
171615.563412.12.XX IN NSAP-PTR reg.bb 4.6.1.
89.474645434241.30393837.171615.563412.12.XX (
IN NSAP-PTR host.reg.bb .)
;;;;;;
;;;;;; NSAP with variable-size field.
;;;;;;
;
; An example of an NSAP format with a variable field size.
; The example is of an X.121 NSAP.
;
<owner> <class> <type> <rdata>
. IN NSAP 37
one-org.com IN NSAP 37.31342023011007.01
two-org.com IN NSAP 37.575654012456.03
37 IN NSAP-PTR com *.1.
01.07100123203431.37 IN NSAP-PTR one-org.com .
03.562401545657.37 IN NSAP-PTR two-org.com .
B. Manning (Rice University) [Page 8]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
8 Security
Security issues are not addressed in this memo.
9 References
[1] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
Service"
USC/Information Sciences Institute, September 1981.
[2] Reynolds, J., J. Postel, "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, July, 1992.
[3] Manning, B., "DNS NSAP RRS", RFC 1348, Rice University,
July, 1992
10 Authors' Addresses
Bill Manning
Rice University - ONCS
P.O. Box 1892
6100 South Main
Houston, Texas 77251-1892
USA
Phone: +1.713.285.5415
EMail: bmanning@rice.edu
Richard Colella
National Institute of Standards and Technology
Technology/B217
Gaithersburg, MD 20899
USA
Phone: +1 301-975-3627 (voice); +1 301 590-0932 (fax)
EMail: colella@nist.gov (Internet)
/C=us/A=attmail/P=gov+nist-gw/S=colella/ (X.400)
A Issues
A.1 User Interfaces
Typical user interfaces, for example nslookup, expect the inverse map string
to be typed from least significant byte to most significant byte followed by
IN-ADDR.ARPA. This isn't too bad for four-byte IP addresses, but can be
excruciating for 20-byte NSAPs. It would be much easier if this reversal
could be done by the software instead of the user. This is especially true
since one convenient way to handle NSAPs is by picking and stuffing values.
So, if we have an NSAP,
47000580005a0000001000002000800a12345601
B. Manning (Rice University) [Page 9]
INTERNET-DRAFT DNS NSAP RRs 05 Apr, 1993
One would like to pick it, stuff it on a command line (e.g., to nslookup),
and append NSAP-PTR.ARPA.:
% nslookup 47000580005a0000001000002000800a12345601.NSAP-PTR.ARPA.
The resolver code could recognize the NSAP-PTR.ARPA domain and perform the
appropriate reversal before issuing the query.
A.4 Relationship to X.500
It may be useful to associate an X.500 distinguished name with an NSAP. Some
thought should be given to whether this is useful and how it could be done.
A.5 NSAP prefixes
Should NSAP prefixes be encoded in the DNS? This may have some useful features.
Expiration: 05 Oct., 1993 [Page 10]
B. Manning (Rice University) [Page 10]
--
Regards,
Bill Manning bmanning@rice.edu PO Box 1892
713-285-5415 713-527-6099 Houston, Texas
R.U. (o-kome) 77251-1892